This new method calculates the static Module address corresponding to the
receiver, effectively discarding any instance keys present in the
containing module instance path.

This is just a variation of the pre-existing ModuleInstance.Call that
returns its result as a single value of type AbsModuleCall.

This should really have been the signature of ModuleInstance.Call in the
first place, but it took us some time to realize that we would benefit
from an absolute address type for module calls themselves as opposed to
the instances they imply once expanded, and so AbsModuleCall didn't
exist at the time we originally wrote ModuleInstance.Call.

Perhaps one day we'll update all existing callers of ModuleInstance.Call
to use ModuleInstance.AbsCall instead, but for now we'll be pragmatic and
keep both to avoid causing unnecessary churn.

This is a similar idea to Expander.ExpandModule but for situations where
we already know exactly which containing module we're evaluating inside,
and thus we can just pluck out the leaf instance keys of that specific
dynamic call, rather than the full recursive expansion of every containing
module.

Expander.ExpandModule is useful when implementing DynamicExpand for a
graph node because main graph nodes always represent static configuration
objects, but this new Expander.ExpandAbsModuleCall is more appropriate
for use during expression evaluation of references to a module call
because in that case we'll know which specific module instance address
we're using as the evaluation scope.

A future commit will actually use this new method from the expression
evaluator in the modules runtime.

We've been gradually improving the design of how we keep track of "named
values" such as output values, but the expression evaluator for output
values was still doing some things in more manual/bespoke way, rather
than making use of the new abstractions.

We'll now use a combination of instances.Expander and namedvalues.State
as the source of truth for which instances exist for a given module call
and what output values each of those instances have.

The configuration remains the decider for which output value names are
declared, but the final result associated with each of the declared output
values is tracked by namedvalues.State.

This also removes the temporary namedvals GetOutputValuesForModuleCall
method we added as a stopgap to allow introducing the namedvals.State
API without such a disruptive rewrite of our output value handling.
We have no further need for that helper because instances.Expander already
knows which instances should exist for each module call, and the
configuration knows which output values should exist in the result, and
so namedvals only needs to be able to return one final output value result
at a time, via namedvals.State.GetOutputValue.

With all of the tricky inline logic factored out of this part of the
evaluator, the TestEvaluatorGetModule test becomes considerably simpler
since it's no longer the evaluator's responsibility to choose between
various different sources for the module output values depending on the
situation, and instead we just need to set the evaluator and the instance
expander up in a realistic way, with the correct handling of both of those
utilities already being covered by this package's main integration tests.